Conversation
patrickroberts
requested review from
JeffGarland,
RaduNichita,
ednolan,
neatudarius and
nickelpro
I think the only viable user intervention here would be no attribute. To me, for any_view this shouldn't really a user facing decision -- it's a required portability difference to support a non-compliant compiler. Not adding the attribute doesn't seem like something we need to document and have the user choose or not. Noting that the library doesn't attempt to support any compiler that doesn't have the attribute capability at all. I also argue that this change doesn't actually violate the intent of 'flag forking'. That is, there's zero risk of down stream linking issues in this case because the library simply selects the correct option for the compiler being used. There's no cross pollination between msvc and gcc at all. And further, the change eliminates a potential packaging issue -- that is, something package with a config.hpp file for gcc will fail to compile with msvc. We need @camio to weigh in -- this will be coming up at the monday sync tomorrow so hopefully we can resolve soon. |
I've made a lengthy comment on this now -- thanks for bring that up. |
3 participants
To me, this particular usage of a configuration header generated by CMake doesn't make sense. As a header-only library, the deployment should allow the target platform to decide which attribute the macro expands to during compilation. The header still checks
#ifndef BEMAN_ANY_VIEW_NO_UNIQUE_ADDRESSin case the user wants to expand a different attribute (or none at all) with-Dor#definebefore including the library.Marking this as draft because I don't anticipate strong consensus on this and am fine with closing if there are good reasons not to go this route.